System and method for using a digital wallet

ABSTRACT

A system and method for using a digital wallet are provided. A request is received from a wallet application on a mobile device of a first user. The request indicates a transfer of a value to a second user. The value is associated with a source selected from a plurality of sources associated with a user account of the first user. The plurality of sources is associated with monetary values and non-monetary values. The value indicated in the request is transferred. The source of the value is updated to reflect the transfer of the value to the second user.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/471,776, filed Jun. 20, 2006, which is a continuation of U.S. patentapplication Ser. No. 09/560,215, filed Apr. 28, 2000 (and issued Aug. 8,2006 as U.S. Pat. No. 7,089,208) and are incorporated herein byreference, and which claims the benefit of U.S. Provisional PatentApplication Nos. 60/131,785 (filed Apr. 30, 1999), 60/144,633 (filedJul. 19, 1999), and 60/172,311 (filed Dec. 17, 1999), all of which arealso incorporated herein by reference.

BACKGROUND

This invention relates to the fields of computer systems andcommunications. More particularly, a system and methods are provided forfacilitating the exchange of value among distributed users throughcomputing devices.

Existing methods of transferring or exchanging values among multiplepersons have many shortcomings. For example, the use of cash requiresregular replenishment, creates the need to make change, allows thepossibility of theft or loss and has no built-in or easy method ofkeeping records concerning cash payments and receipts. Similarly, checkscan be forged, they often provide only rudimentary record keeping (e.g.,check stubs) and allow one to unwittingly overdraw a checking account.Credit cards may mitigate some of the problems with cash and checks, butcannot be used for making payments or exchanging value between two ormore individuals.

In addition, the formalities of existing value exchange transactions canmake them inefficient or difficult to complete. For example,transferring money to another person's bank or other financial accountmay require one to know the person's account number. That person mayunderstandably be reluctant to divulge such information.

Thus, what is needed is a system and method for enabling value transferswithout all the shortcomings of existing means and techniques. It wouldbe desirable, for example, to allow a value exchange transaction to beconducted using a known or common identifier of a person (e.g.,electronic mail address, telephone number) rather than other, moresensitive, information.

SUMMARY

In one embodiment of the invention a system and methods are provided forconducting a value exchange between two or more persons using adistributed value exchange system.

In this embodiment the system may comprise one or more system serversconfigured to register a person or other entity (e.g., a business) as asystem user and allow him or her to conduct value exchange transactionswith persons who may or may not also be registered users. A user thenemploys a client computing device (e.g., a handheld, palmtop or desktopcomputer, a web-enabled telephone, a two-way pager) to initiate orconduct a value transfer. The value exchange may be conducted whileonline with (e.g., connected to) the system, while offline, whileconnected (e.g., via wireless connection) to another user's device, etc.When the transaction is submitted to the system, it notifies transactionparties that are as-yet unaware of the transaction and attempts to clearor finalize the transaction and adjust the users' account balancesappropriately.

A communication server may be configured to receive connections (e.g.,wired and/or wireless) from persons wishing to become registered users.A synchronization server may be configured to facilitate thesynchronization of user's client devices with the system. Duringsynchronization, users' devices may submit transactions to the system,receive information on new or cleared transactions, synchronize accountinformation on the system with the information on the client device,etc. A security server may be configured to enforce security procedures,possibly using asymmetric and/or symmetric cryptographic techniques. Afinancial server interacts with other system servers and externalfinancial institutions to enable a user to inject value into the systemand withdraw value from the system. One or more databases may storeaccount information for users (e.g., account information, transactiondetails) and help coordinate system activity.

In one method of conducting a value exchange a person registers with thesystem, an account is created for him and system software is downloadedto his client device. The user may then conduct transactions on hisclient whether he is connected to the system or not. When not connected,the client stores transaction details and, when later connected to thesystem for synchronization purposes, uploads his transactions to thesystem and may receive transactions initiated by other users. Eachtransaction may include an identifier of another party to thetransaction and the value to be exchanged. In one embodiment of theinvention transaction parties may be identified by identifiers that havemeaning outside the system, such as electronic mail addresses, telephonenumber, social security numbers, etc. Thus, the user may initiate atransaction with a person who is not a registered user as long as heknows an appropriate identifier of the person.

When the system receives a new transaction initiated by a user itattempts to contact the other party or parties using the identifier(s)provided by the initiating user. If another party is a registered user,the system may also know other methods of contacting the party. For aparty who is not already a user, he or she is invited to connect to thesystem, register and complete the transaction.

Virtually any means of value transfer may be associated with the system.Users may introduce value into their system accounts via credit card,check, cash, electronic funds transfer, direct deposit, etc. Value maybe withdrawn from the system using the same or similar processes. Thevalue that is exchanged between transaction parties may be monetary(e.g., represented by United States dollars or other currency) or havesome other form, such as credits, affinity points, frequent flier miles,vouchers, barter points, etc.

DESCRIPTION OF THE FIGURES

FIG. 1 is a block diagram depicting a system for conducting valueexchange transactions in accordance with an embodiment of the presentinvention.

FIG. 2 is a flowchart illustrating one method of conducting a valueexchange transaction in accordance with an embodiment of the invention.

FIG. 3 depicts one form of an indirect value exchange transaction from afirst user to a second user performed on the first user's mobile clientdevice in accordance with an embodiment of the invention.

FIG. 4 depicts one form of a direct value exchange from a first user toa second user conducted with the user's mobile client devices inaccordance with an embodiment of the invention.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled inthe art to make and use the invention, and is provided in the context ofparticular applications of the invention and their requirements. Variousmodifications to the disclosed embodiments will be readily apparent tothose skilled in the art and the general principles defined herein maybe applied to other embodiments and applications without departing fromthe spirit and scope of the present invention. Thus, the presentinvention is not intended to be limited to the embodiments shown, but isto be accorded the widest scope consistent with the principles andfeatures disclosed herein.

The program environment in which a present embodiment of the inventionis executed illustratively incorporates a general-purpose computer or aspecial purpose device such as a hand-held computer. Details of suchdevices (e.g., processor, memory, data storage, display, wired/wirelesscommunication capability) are omitted for the sake of clarity.

It should also be understood that the techniques of the presentinvention might be implemented using a variety of technologies. Forexample, the methods described herein may be implemented in softwareexecuting on a computer system, or implemented in hardware utilizingeither a combination of microprocessors or other specially designedapplication specific integrated circuits, programmable logic devices, orvarious combinations thereof. In particular, the methods describedherein may be implemented by a series of computer-executableinstructions residing on a storage medium such as a carrier wave, diskdrive, or computer-readable medium. Exemplary forms of carrier waves maytake the form of electrical, electromagnetic or optical signalsconveying digital data streams along a local network or a publiclyaccessible network such as the Internet.

Introduction

In one embodiment of the invention a system and method are provided forfacilitating an exchange of value between two or more persons usingclient computing devices. Values that are exchanged may be monetary innature (using any currency) or may take other forms, such as credits,debits, discounts, vouchers, certificates, mileage (e.g., frequent fliermiles), etc. The computing devices used to conduct an exchangetransaction may or may not be portable in nature, and may employvirtually any communication media, including both wired and wireless. Inone implementation of this embodiment, at least one user employs aportable computing device such as a handheld or palmtop computer, asmart telephone, a two-way pager, etc. A computing device suitable forthis embodiment may always be linked to or in communication with anotherdevice (e.g., a system server), such as a networked personal computer,or may be disconnectable, such as a hand-held personal digital assistant(PDA). Thus, a value exchange transaction may be conducted offline oronline, while connected or disconnected from other system components.

A system according to this embodiment of the invention includes at leastone highly accessible computer server configured to facilitate valueexchanges. Illustratively, a user who wishes to initiate a valueexchange or value transfer with another party is registered with theserver beforehand (e.g., an account is established for the user on theserver). The other party may or may not be a registered user at the timethe transaction is initiated or communicated to the system.

In one method of conducting a value exchange according to thisembodiment of the invention an entity involved in the exchange may beknown by an identifier that has meaning or use outside of the system,such as an electronic mail address, a telephone number, a socialsecurity number, etc. Illustratively, each such identifier is onlyassociated with one person or entity, thus promoting accountability. Inan alternative method, however, multiple users or accounts may beassociated with an identifier.

In one implementation of a method of conducting a value exchange aregistered user of the system initiates an exchange with an unregisteredparty by identifying that party to the system server by his or herelectronic mail address. The registered user may provide various detailsof the value exchange, such as the form of the value (e.g., a monetaryamount, a number of credits or affinity points), a date on which toeffect the transfer, the unregistered party's name, etc. The system maythen attempt to contact the unregistered party (e.g., via the providedelectronic mail address), notify him or her of the value exchange,identify the initiating user and invite the unregistered party toconnect to the server and close the exchange. The unregistered party maybe required to register with the system in order to close thetransaction. For example, if the value exchange is to the benefit of theunregistered user, he or she may wish to leave the value in the systemin order to use it to conduct an exchange with yet another party.Alternatively, the unregistered party may be permitted to provide justenough information (e.g., credit card number, address) to allow thesystem to close the transaction, without being registered.

In different embodiments of the invention the value exchange may beinitiated by the person who owes or is owed the value to be exchanged.Further, the value that is exchanged may be of virtually any form and/ormay be transformed in nature. For example, a monetary amount or a creditor voucher held by a first user and accepted by a second user may betransferred from the first user to the second user in exchange for goodsor services. Or, the value may change from one currency to another orfrom being monetary in nature to being represented by credits with amerchant, frequent flier miles, or some other value. Thus, a user maypay for goods or services with value in many different forms, includingcurrency or points that are used only within the system (e.g., fortransactions between users).

The system may also be configured to allow users to perform normalbanking operations (e.g., withdrawals, deposits, transfers), stocktransactions, electronic ticketing, etc. In another embodiment of theinvention a third party may be involved to hold the value in escrowuntil a transaction is closed.

Value may be introduced into the system (and credited to a user'saccount) via cash, check, debit, or virtually any other method that ispresently used or that becomes accepted in the business community. Valuemay exit the system in these and similar forms.

In alternative embodiments of the invention a distributed systemdescribed herein may be used for forms of communication other than valueexchanges. For example, in one alternative embodiment the system may beused to spread or disperse software among multiple users.Illustratively, a registered system user could then provide anunregistered person with the system software and thereby allow them toconduct a transaction. Advantageously, the software could be transmittedbetween users' client devices using wired or wireless communications.

One Embodiment of a System for Facilitating a Value Transfer

FIG. 1 depicts an illustrative system for facilitating value transfersaccording to one embodiment of the invention. Alternative embodiments ofthe invention may incorporate any subset of the components of theillustrated system.

The system of FIG. 1 includes central database 102, which is configuredto store various information used to facilitate value exchangetransactions. Illustratively, the information stored in database 102includes accounts for registered users of the system as well as variousinformation pertaining to unregistered users participating in or invitedto participate in a transaction. User information for registered and/orunregistered users may include user identifiers (e.g., name, electronicmail address, telephone number, network address, physical address),transaction records, account balances in one or more different forms(e.g., money, frequent flier miles, store credits, affinity points,vouchers, coupons, discounts), preferred communication methods (e.g.,electronic mail, wireless voice), security data, etc.

In the system of FIG. 1, database 102 is accessed by communicationserver 104, synchronization server 106, financial server 108 andpossibly security server 110. In this embodiment, communication server104 and/or other system servers are configured to interact with one ormore users through communication network 120. For example, communicationserver 104 may be or may include a web server, telephone switch, DSLAM(Digital Subscriber Line Access Multiplexer), etc.

A network presence, such as a web site on the Internet, that is hostedby communication server 104 may serve as a primary access point to thesystem for new and, possibly, existing users. Illustratively, users aregiven account names and passwords with which to access the system afterbeing registered. Other forms of security (e.g., digital certificates,biometric devices) may be employed in other embodiments of theinvention.

In one embodiment of the invention a user may download software for hisor her computing device from communication server 104. In particular,communication server 104 may allow a person to register with the system,access and/or modify account information, conduct and cleartransactions, etc. A user may be required, however, to register with thesystem before being able to initiate or close a transaction.

Synchronization server 106 in the illustrated embodiment is configuredto synchronize information stored on the system with users' clientcomputing devices and locally stored data. Illustratively, a user mayconnect to the synchronization server to upload and/or download detailsof transactions (e.g., value exchanges) that involve the user. During asynchronization session, a user's client may receive updated accountinformation (e.g., reflecting cleared transactions), may authorize thesystem to charge additional funds to the user (e.g., by charging acredit card or transferring funds from a bank account), access customerservice, query the status of a transaction, initiate a new transaction,etc.

Financial server 108 is configured to interface with one or morefinancial institutions, which may, in one embodiment of the invention,be external to the system. Thus, the financial server may interact withcredit card companies, banks (including traditional and online banks)and other entities that handle or process value in suitable forms; inparticular, the financial server may be configured to transfer fundsthrough the ACH (Automated Clearing House). Financial server 108 may beconfigured to automatically generate a charge or credit to a user'saccount with an external financial institution when the user's systemaccount balance falls below or rises above a predetermined threshold.Further, the external value that the system can access for a userthrough financial server 108 may affect the number of transactions thatthe user can conduct or the amount of value in a transaction.

Security server 110 may cooperate with one or more of database 102,communication server 104, synchronization server 106 and financialserver 108 to apply, ensure or enforce security for value exchanges andactions related to value exchanges. In one embodiment of the inventiondigital signatures may play a large part of the security scheme. DSA(Digital Signature Algorithm), a variant thereof (e.g., ECDSA orElliptical Curve DSA), RSA or other digital signature protocol may beused. Symmetric cryptographic schemes such as DES (Digital EncryptionStandard) may also be applied in the same or different embodiments.Message authentication codes may be used to verify the integrity andauthenticity of messages exchanged between the system and a user.

In a present embodiment of the invention public key encryptiontechniques may be used with digital certificates to createcryptographically verifiable transactions and prevent their repudiation.Symmetric encryption schemes may be employed for secure storage of data(e.g., on users' client devices and/or on the system).

Illustratively the organization operating the value exchange system mayact as a Certificate Authority and certify individual users, whilecertified users may, in turn, certify individual transactions. Certifiedusers may be issued identity certificates for use in value exchangetransactions.

An identity certificate may include information such as the user's name,electronic mail address (or other meaningful identifier that identifiesthe user, such as a telephone number or social security number), accountnumber or name, etc. Illustratively, an identity certificate alsoincludes a public key of the user, which may be used to verify theauthenticity of transactions conducted by the user.

Individual users generate transaction certificates for transactions theyconduct or initiate and the system authenticates them with the users'public keys (e.g., during synchronization). A transaction certificatemay include the value being exchanged, an identifier of another party tothe transaction, other details (if necessary or desired), and may besigned with the user's private key. In one embodiment, a user's clientcomputing device generates the public/key pair during user registration,and the private key is retained only on the client device.

The illustrated system may communicate with users through various typesof communication media. Communication network 120 may thus comprise atraditional wired network (e.g., the Internet) and/or a wireless networkusable by portable devices such as portable computers (e.g., palmtop orhandheld), smart (e.g., web-enabled) telephones, two-way pagers, etc.Therefore, users may interact with the system by operating devices suchas client computer 122 a, portable client computer or digital assistant122 b, wireless telephone 122 c and/or other devices capable ofcommunicating with communication server 104 and/or synchronizationserver 106. Illustratively, portable client computer 122 b may beconfigured to conduct value exchanges with, or communicate them to, thesystem independently and autonomously. Or, in an alternative embodiment,portable client computer 122 b may be operated to record details of anexchange in a disconnected mode and then, when connected (e.g., docked)with another computing device (e.g., computer 122 a) to forward thosedetails to the system in order to finalize the exchange, and/orsynchronize with the system.

A portable client device employed by a user to participate in a valueexchange transaction may incorporate a series of instructions forinteracting with the system. For example, in one embodiment of theinvention a user's client device includes a wallet application thatallows the user to access his or her account balance(s) while connectedto the system and/or while disconnected from the system. Illustratively,in this embodiment of the invention a user's device periodicallyconnects to synchronization server 106. During such a connection theuser's device communicates with the server to send and receive newtransaction information (e.g., details of new value exchanges involvingthe user) and/or receive updated account information (e.g., to reflectclosed transactions). The user may also authorize or perform otheractivities involving his or her account, such as transfer value to orfrom a system or institution external to the value exchange system.

One Method of Conducting a Value Exchange

In one embodiment of the invention a value exchange transaction may beconducted by a single user (e.g., with his client device), whileconnected to or disconnected from a system server (e.g., communicationserver 104, synchronization server 106 of FIG. 1) or another party'sclient. In particular, in one embodiment of the invention a userinitiates a transaction by submitting it to the system, which then takesaction to close the transaction by notifying another participant, andpossibly registering the other participant with the system. In analternative embodiment, however, a transaction may be conducted in adirect communication between two (or more) parties, after which detailsof the transaction are submitted to one of the system servers. In thisalternative embodiment, at least one of the parties (e.g., from whomvalue is being transferred) may be required to be registered with thesystem.

Illustratively, a transaction cannot be closed or finalized until thesystem learns of the transaction from one of the involved parties,identifies the other participant(s) and determines how to transfer thevalue. Closure of a transaction may include the actual transfer of valuefrom one party (e.g., in a first account and/or form) to a second party(e.g., to another account and/or form). Parties to a transaction mayneed to be registered with the system and/or provide certain information(e.g., to identify a party, verify a party's identity, determining howto transfer value to or from the party) before the transaction can beclosed.

In this section, one or more methods are described for using a valueexchange system such as that depicted in FIG. 1 to effect a valueexchange between two or more parties. The methods and operationsdescribed here may be altered or modified for different types ofcomputing devices that a party may employ and/or different system ortransaction configurations without exceeding the scope of the invention.

In one embodiment of the invention the system of FIG. 1 may beenvisioned as a system for facilitating or conducting a financialtransaction involving two or more persons. Illustratively, at least oneperson in the transaction is already registered (e.g., has an account)with the system so that at least one form or conduit for transferringvalue exists. Advantageously, however, a registered user may initiate atransaction with an unregistered party, who may be identified to thesystem with an existing identifier such as an electronic mail address,telephone number, IP (Internet Protocol) address, etc. Thus, in thisembodiment identifiers associated with unregistered users (and/orregistered users) may already have significance or use outside of thesystem and there may thus be some degree of assurance that they can bereached through or with those identifiers.

Once known to (e.g., registered with) the system, however, a user mayconduct value exchanges and other transactions using portable,semi-portable and other computing devices. In particular, the systemenables a user to conduct a secure transaction from his or her clientdevice directly (e.g., to another user or person having a compatiblyequipped device) or indirectly (e.g., by describing or submitting thetransaction to a system server, which may then notify anothertransaction party).

Illustratively, in a direct transfer the parties may exchangecryptographic tokens in order to prevent later repudiation andauthenticate the transaction to the system, and, once the system isinformed of the transaction by at least one party, the transaction canbe closed. In an indirect transfer the system may contact another party(e.g., by electronic mail or telephone) on behalf of an initiating userand, if the party is not already registered, invite that party toregister with the system in order to receive and/or conduct their owntransfers or exchanges. In one embodiment of the invention the invitedparty may, of course, be able to satisfy his or her part of thetransaction (e.g., receive or pay money or other value) withoutregistering with the system. For example, he may send payment to orreceive payment from the system in a traditional form (e.g., check,credit card, debit card).

With reference now to FIG. 2, an illustrative method of conducting anindirect value exchange transaction according to one embodiment of theinvention is presented. The illustrated method is suitable for use withthe system depicted in FIG. 1.

In state 200, a first user (USER1) registers with the system, one methodof which is described in a following section. Illustratively, as part ofthe registration process USER1 provides his or her name andresidence/postal address, a meaningful identifier (e.g., electronic mailaddress, telephone number, social security number) and pertinentfinancial information. Financial data provided by USER1 may include acredit card or bank account to be credited or charged for individualtransactions and/or when the value of a transaction exceeds apredetermined limit. In particular, users may be assigned limits on howmuch value they can transfer through the system, based on the financialdata regarding them, the degree to which their personal information(e.g., address) can be verified, etc. The limit may affect the size ornumber of uncleared transactions that a user may be involved in at agiven time.

A registered user may be assigned an account number or other identifierwithin the system. As mentioned above, however, a party may be includedin a transaction by specifying an externally meaningful identifier(e.g., electronic mail address, telephone number) associated with theparty. USER1 may register with the system, and conduct transactions,using virtually any form of client device (e.g., handheld or palmtopcomputer, desktop, web-enable telephone) having the ability tocommunicate with another computing device (e.g., a system server).

In the presently described embodiment of the invention a digitalcertificate is generated for or provided by USER1 as part of theregistration process. Illustratively, a certificate generated for USER1includes USER1's name and electronic mail address (or other meaningfulidentifier) and a public key signed by the system, all of which areencrypted by a code (e.g., a Personal Identification Number or PIN)previously assigned to or chosen by USER1. In one method of registeringa user described in a later section, a public/private pair ofcryptographic keys is generated (e.g., by the user's client or securityserver 110) and the private key is retained only by the client or othercomputer system operated by the user.

In state 202 USER1 enters a transaction in his client using softwareprovided by the system. Illustratively, USER1 simply enters theelectronic mail address, telephone number or other identifier of a party(e.g., USER2) with whom he wishes to exchange value, plus the value tobe transferred. In this embodiment, the value may flow in eitherdirection (i.e., from or to USER1). The amount of value that USER1 maytransfer (if the value is to flow to USER2) may be limited to his systemaccount balance (e.g., which may be stored on his client and updatedwhen the client synchronizes with the system). This amount may bedecreased by any other transfers (to other users) that have beenrequested or initiated but not yet cleared. If, however, USER1 hasprovided other payment arrangements (e.g., through a credit card,electronic funds transfer), then he may be able to exceed his accountbalance.

USER1 may be required to enter a security code (e.g., PersonalIdentification Number or password) to activate the client systemsoftware before entering a transaction. Illustratively, if an incorrectcode is entered a predetermined number of times (e.g., ten), the abilityto enter transactions may be disabled and USER1 may be required tocontact or synchronize with the system (as described below) in order tore-enable the client software.

The software may maintain a list of all parties with whom USER1 haspreviously conducted a value exchange transaction, in which case he mayjust select USER2's identifier if she is included in the list. Theclient system software employed by USER1 may offer multiple transactionoptions. For example, USER1 may be able to initiate a unilateraltransfer to (or from) USER2. USER1 may also be able to initiate abilateral transaction if his client and USER2's client are capable ofdirect (e.g., wireless) communication. Yet further, USER1 may be able totransmit the client system software to USER2's client device. In thiscase, however, USER2 may not be able to transfer value to another partyuntil she registers with the system (and opens an account).

At some time after entering the transaction in his client, in state 204USER1 synchronizes with synchronization server 106. In particular, USER1initiates whatever commands or actions are necessary to connect hisclient with the synchronization server. The client may be able toconnect directly, perhaps through a wireless connection, or through anynumber of intermediate devices or media (e.g., the Internet). Inparticular, if USER1's client is a portable device, he may be requiredto dock it or otherwise connect it to another computer system in orderto initiate a connection to synchronization server 106.

Synchronization may be required on a regular basis (e.g., at least onceevery thirty days). If this requirement is not satisfied, the clientsoftware may automatically prevent USER1 from making payments orinitiating transactions. In addition, transactions made on USER1'sclient may be automatically canceled or nullified if he does notsynchronize within a certain period of time (e.g., thirty days) afterentering the transaction in the client.

In a typical synchronization process according to one embodiment of theinvention, USER 1's client connects to synchronization server 106 andidentifies USER1 by his system account number (and/or electronic mailaddress, telephone number or other meaningful identifier). The serverlocates a user record for USER1 (e.g., in database 102) and retrieves acode (e.g., a PIN) assigned to or associated with the user. A digitalcertificate associated with USER1, and which is to be transmitted toUSER1 during synchronization, is then encrypted with this code; thisdigital certificate may be the certificate that was generated when USER1was registered. Illustratively, however, the digital certificate may beaugmented with one or more transaction certificates for transactionsinvolving USER1 that have been reported to the system by other users.The digital certificate may also be used to pass a new code (e.g., PIN)to USER1.

If there is no digital certificate stored on the system for USER1, thesynchronization server requests USER 1's password and electronic mailaddress (or other identifier). If this information is verified, a newkey pair may be generated and a new digital certificate issued.

After the initial synchronization connection is established, the clientsends the present transaction (and any others it has stored and notalready sent) to the server. The transactions may be sent using digitaltransaction certificates, as described above. The client is informed ifany previous transactions of USER1 have cleared (e.g., another party ina previous transaction may have connected to the system and accepted thetransaction), in which case they may be removed from the client. Theserver may then prioritize uncleared transactions according to somecriteria (e.g., date, time, other party or parties, transaction value,direction of value transfer).

A user's client (and/or a system server) may maintain a transaction login which to record transactions conducted by and/or involving the user.An entry is then made in the log when the user initiates a transaction.An entry may also be made in the log for each transaction (e.g.,initiated by another party) that the client learns of from a systemserver (e.g., during synchronization). Entries may be removed orarchived after their associated transactions clear.

In one method of the invention account balances are altered during thesynchronization process. In particular, USER1's account is debited forall values being transferred away from USER1. Conversely, however,USER1's account may not be credited for incoming value transfersinitiated by USER1 until the other parties to such transfers synchronizeor otherwise acknowledge or approve them (e.g., until the transactionsclear). If USER1's system account has an insufficient balance to make atransfer (e.g., to USER2), his credit card or other value stream may betapped (e.g., by financial server 108) to cover them.

Thus, in state 204, once USER1 has connected to the synchronizationserver the transaction is communicated to the system along with anyother transactions not yet submitted. In exchange, the synchronizationserver may inform the client of any closed transactions and downloadtransactions that involve USER1 that were initiated by other parties.Therefore, the synchronization process of state 204 may involve updatingUSER1's client and the system with various transactions to which USER1is a party. Account balances on a system server and/or the client may bealtered accordingly during the synchronization process or afterwards.

In state 206 a system server (e.g., synchronization server 106) receivesthe details of the USER1/USER2 transaction (e.g., including anidentifier of USER2 and the value to be transferred). If the valueexchange is from USER1 to USER2, USER1's account may be automaticallydebited by the amount of the transfer; this may require a charge to acredit card or bank account associated with USER1. In the illustratedembodiment, however, account updates may be postponed until a laterstage of the procedure.

In state 208 the system attempts to inform USER2 of the transaction. Inthis embodiment the system uses the identifier submitted by USER1 (e.g.,by generating an automated electronic mail message or voice message).If, however, USER2 is a registered system user, her account may beexamined to determine if she has a different, preferred, method ofreceiving transaction communications. If USER2 is not a registered user,the automated message includes details concerning what she should do toreceive the value. For example, a system web site hosted bycommunication server 104 may be identified and USER2 invited to connectto the site and register.

In state 210, which may occur simultaneously with state 208, the systemdetermines whether USER2 is a registered user. If so, then she need notregister and the procedure continues at state 214.

In state 212, however, USER2 is unregistered at the time of thetransaction with USER1 and therefore may be required to register beforethe transaction can be closed, particularly if the value is to betransferred from USER2 to USER1. By registering with the system, USER2may receive or submit the transaction value using virtually any normalmeans for conveying value (e.g., credit card, check, debit card,electronic funds transfer). However, in one alternative embodiment ofthe invention USER2 may not be required to register. In particular, inthis alternative embodiment she may be able to make a one-time paymentto or withdrawal from the system (e.g., with a credit card or check).

In state 214 USER2 accepts or acknowledges the transaction. Acceptancemay be implied if she was an unregistered party and registers inresponse to the invitation from the system. State 214 may only berequired for transactions in which the value is to be transferred fromUSER2 to USER1. In other words, when a first user initiates atransaction to transfer value to another user, the other user'sacknowledgement may not be needed. However, if a first user initiates atransaction to receive value from another user, it may be necessary toreceive approval from the other user before closing the transaction.

In state 216 the transaction is closed by altering system accountbalances for USER1 and USER2 according to the value of the transaction.In addition, the user that is providing value to the other party mayneed to inject additional value into the system in order to cover thetransaction. Thus, financial server 108 may charge the user's creditcard, conduct an electronic funds transfer or take other action.Further, if there is a limit or maximum on the receiving user's accountbalance, the financial server may credit value to his or her creditcard, debit card, bank account, etc.

In state 218 the client devices for USER1 and USER2 are updatedaccording to the transaction (and, possibly, other transactions). If,however, USER1 or USER2 are disconnected from the system at the time,their devices may be updated (e.g., by synchronization server 106) thenext time they connect. After state 218 the illustrated procedure ends.

In a present embodiment of the invention USER1 may be granted affinitypoints or some other reward for introducing a new user to the system. Inparticular, if USER2 was not a registered user at the time USER1submitted the transaction to the system, he may be rewarded if USER2registers in response to the transaction notification from the system.

The embodiment of the invention illustrated in FIG. 2 and describedabove is but one method of conducting a value exchange with a systemsuch as that depicted in FIG. 1. This method may be readily modified toaccommodate the use of various types of client devices, communicationmedia and communication sequences. In particular, the preceding methodmay be applied as described, or slightly altered, to conduct a valueexchange between a registered user and an unregistered party, betweentwo or more registered users, or in virtually any circumstance in whichvalue is being exchanged.

FIG. 3 depicts one form of an indirect value exchange performed by oneuser on a mobile client device. In FIG. 3 UserA enters the valueexchange in her device, ClientA. The transaction is then submitted to asystem server, possibly during a synchronization process. The amount ofthe value (if UserA is authorized to transfer the full value) is removedfrom UserA's account and UserA's client device is updated with her newaccount balance. Additional funds or value may be retrieved from a bank,credit card, ACH, or other financial source associated with UserA if heraccount balance falls below a minimum level or the transfer is necessaryin order to complete the requested exchange. The value is deposited inUserB's account, which may require an account to be created for UserB ifhe is not already a registered user.

In one embodiment of the invention the value of a transaction may beheld in escrow. In this embodiment the user initiating the transactionchooses an option to have the value placed in escrow. If this user isthe payor (e.g., the party from whom value is being transferred), theuser's account may be debited as soon as the transaction is communicatedto the system, but instead of being credited to the specified recipient,it is held in an escrow account. Illustratively, the value recipient isnotified that a value is being held and, possibly, the conditions forreleasing it. The system may require that both parties agree before thefunds are transferred to the recipient or back to the payor. The systemmay be configured, by default, to complete the transfer after a certainperiod of time if there is no objection from a party or, conversely, tocancel the transaction unless one or both parties affirm it within thespecified period of time.

The following sub-sections describe methods of conducting a valueexchange in different environments or circumstances from those describedabove.

Conducting an Online Value Exchange

In one alternative method of conducting a value exchange, a userconnects to the value exchange system (e.g., the system of FIG. 1)through an Internet connection (e.g., from a desktop or wirelessclient). In this method, communication server 104 of the system of FIG.1 comprises a web server hosting a web site for the system. A userwishing to initiate a transaction connects to communication server 104and satisfies the necessary security requirements by providing ausername, account name or other identifier (e.g., electronic mailaddress, telephone number) and a password. In one alternative of thisembodiment, a cryptographic security policy may be enforced thatrequires the user to provide cryptographic authentication or a securitytoken.

The user completes an online form by providing information such as anidentifier (e.g., electronic mail address, telephone number, socialsecurity number, account name) of another party to the transaction andthe value to be transferred. Also, the user may specify whether thevalue is to be transferred from him to the other party or vice versa.The user's interface with the system (e.g., the web page presented tothe user when he connects or logs in) may be personalized to the user.In particular, identifiers of parties with which the user has transactedin the past may be available for ready selection, in which case the userneed not remember or enter an identifier but can, instead, pick one froma list.

If the other party is already a registered system user, the system maythen proceed to conduct the value transfer. Illustratively, if the valueis to flow from the initiating user to the other party, the system maynot require the approval or authorization of the other party to finalizeor close the transaction. The system may simply send notification of thetransaction (e.g., via electronic mail) to the party. In contrast, ifthe value is to flow from the other party to the initiating user, thesystem may require the other party's approval before closure. When thevalue of the transaction flows from the initiating user to the otherparty, the user's account may be debited by the amount to be transferredeven before the transaction closes (e.g., before the other party acceptsthe transaction).

If the other party is not a registered system user, the system notifiesthe party of the pending transaction by using the identifier provided bythe initiating user. The notification may thus be sent via electronicmail. Illustratively, the notification identifies the user who initiatedthe transaction, informs the other party of the amount of thetransaction and specifies how/where (e.g., a web page or site) tocomplete the transaction. In order to receive the value or submit thevalue requested by the initiating user, the other party may then connectto the system and register. A method of registering a new user isdescribed in a following section.

Unlike an offline transaction (e.g., using a disconnectable portablecomputing device), when conducting a transaction online a user may beable to access account information and/or close the transaction in realtime.

The method of the invention described in this sub-section is suitablefor application with clients that can establish and maintain a real-timelink with the system, whether through the Internet via a wired orwireless connection, through a telephone connection (wired or wireless),etc.

Conducting a Direct (Client to Client) Value Exchange

In one alternative embodiment of the invention a method is provided inwhich two parties employ their client computing devices to conduct avalue exchange. If they are disconnected from the system whileconducting the transaction, after the transaction one or both of themsubmit the transaction to the system (e.g., via communication server 104or synchronization server 106 of the system of FIG. 1). This method isparticularly suited to the use of mobile computing devices and smart orweb-enabled telephones that can communicate directly (e.g., via a wiredor wireless communication medium) with another client.

The option to conduct a client-to-client transaction may be just one ofseveral options available to a user. For example, the system softwareinstalled on the client device may also enable one user to transmit thesystem software to another user, conduct a unilateral transaction (e.g.,as described above in conjunction with FIG. 2), view his or her accountbalance(s) (which are updated each time the client is synchronized) ortransaction log, use a calculator, etc.

If the user elects to make a client-to-client transaction, the user'sclient may automatically attempt to establish contact with anotherclient. The client may be configured to make such connections in awireless or wired mode.

In this method each user activates his or her computing device and oneof them operates the installed system software to initiate a payment toor from the other user. This may require the user to enter a PersonalIdentification Number (PIN) to activate the software. The other user'sclient may then prompt him or her to accept or reject the transaction,particularly if the value of the transaction is to be transferred fromthe other user to the first user. If only one user has the softwareinstalled, the software may be transmitted to and installed on the otheruser's device as part of, or as a precursor to, the transaction.

Illustratively, the account balance of the user giving the value (e.g.,as indicated in the system software) decreases when the transaction isconducted. Closing the transaction may require the paying user's creditcard, debit card or other method of providing value to the system to becharged (e.g., if his or her account balance is too low). Thetransaction may not be closed until one of the users forwards thetransaction to the system (e.g., during a synchronization session withsynchronization server 106). The client software may allow a user tomake notes or comments to be saved in a transaction log with the details(e.g., value, other user's identifier) of the transaction.

In one method of conducting a direct value exchange, the users mayexchange digital certificates (e.g., transaction certificates) or othertokens in order to authenticate each other and/or demonstrate to thesystem that the transaction is valid and was not spoofed or faked by oneof the parties.

FIG. 4 depicts one form of a direct value exchange performed between twousers having mobile client devices. In FIG. 4 UserA electronicallytransfers the value from her ClientA to UserB's ClientB. The transactionis then submitted to a system server by one of the transaction parties,possibly during a synchronization process. The amount of the value (ifUserA is authorized to transfer the full value) is removed from UserA'saccount and deposited in UserB's account. Additional funds or value maybe retrieved from a bank, credit card, ACH, or other financial sourceassociated with UserA if her account balance falls below a minimum levelor the transfer is necessary in order to complete the requestedexchange. Both of the users' client devices are updated with their newaccount balances.

Canceling a Value Exchange

In various situations a user may wish or need to reverse or cancel avalue exchange. For example, while attempting to conduct a transactionwith another party a user may provide an incorrect identifier—such as anon-existent or invalid electronic mail address or a valid electronicmail address that is associated with someone other than the desiredparty. In one embodiment of the invention a value transfer may be undoneif the situation warrants. In particular, if it is determined that anexchange should be undone, the system may cancel the value transfer,reverse it, redirect it (e.g., transfer the value to a third party) ornullify it in some other manner.

If an identifier of a transaction party (e.g., electronic mail address)provided by a user is unusable (e.g., invalid), the user may specifywhether to reverse or redirect the transfer or the system may apply adefault action (e.g., return the value to the user). This situation mayoccur, for example, if an electronic mail notification of thetransaction to the other party is undeliverable (e.g., incorrectaddress, party's electronic mail server is unavailable).

If the party identifier is a valid identifier, but is not associatedwith the intended party, rectifying the situation may be more difficult.For example, if the transaction has already been closed and the valuecredited to the incorrect party, the transaction may be irreversible.The initiating user may, of course, contact that party and attempt toretrieve the value.

If the party identifier is valid but is not associated with the intendedparty and the transaction has not yet closed, the user may be able toretrieve the value. Some period of time (e.g., six months) may beestablished for automatically canceling or reversing unclearedtransactions or during which the user may request cancellation of thetransaction. For example, if a user initiates a transaction and sixmonths later the recipient still has not claimed the value, the systemmay automatically reverse or cancel the transfer. Before that time,however, the initiating user may have to request the transaction benullified. The system may attempt to contact the incorrect party beforedoing so.

Registering a New User in One Embodiment of the Invention

As described earlier, in one embodiment of the invention a user must beregistered with the value exchange system before being able to initiateor close a transaction with the system. This section describes onemethod of registering a new user, during which the user may download orotherwise receive software configured to allow the user's client deviceto interact with the system and/or other user's clients.

Illustratively, a new user may register with the system in many ways,such as through a system web site, via a web-enabled telephone, vianormal voice telephone contact, via electronic or normal mail, etc. Thelevel of access or degree to which a user may employ the system afterregistration may, however, depend upon how the user registers, how muchinformation is provided during registration, how much of the informationis verified, etc. For example, if a user-provided telephone number,electronic mail address, street address, and/or other information is allverified, the user may be granted greater system access or be allowed toconduct transactions involving more value than if the information isincorrect, unverifiable or not provided.

In one embodiment of the invention a potential new user connects tocommunication (e.g., web) server 104 of the system of FIG. 1 andcompletes a registration form. Advantageously, the registration processis done in a secure mode (e.g., with SSL (Secure Sockets Layer)). Theregistration form may elicit or require personal information such asname, residential (e.g., street) address, telephone number(s) (e.g.,daytime, nighttime, mobile), etc. Information to be associated with theuser's account is also requested, such as an electronic mail address,social security number, some information that may be used for securitypurposes (e.g., mother's maiden name), etc. The user may also beprompted to enter a password to be used for the new account and/or a PIN(Personal Identification Number) for activating system software on theuser's mobile device. Illustratively, when the user wishes to initiateor accept a transaction while using his mobile device, he may berequired to enter the PIN before the software will function.

The user may be required to agree to specific terms for using thesystem. The system may then attempt to verify one or more pieces ofinformation provided by the user. Thus, a confirmation communication maybe sent to the user's street address, electronic mail address, mobiledevice, etc. A confirmation communication may include a code (e.g., aPIN) that the user is instructed to provide to the system (e.g., webserver 104) in order to complete or continue the registration process.

In an embodiment of the invention in which a new user registers with thesystem using a smart or web-enabled telephone, the registration processmay be tailored to the device and the limited display means of such adevice. Thus, some of the registration information (e.g., telephonenumber, name) could be derived from the telephone or the signal receivedfrom the telephone. And, the information required of the user may bereduced to a minimum if it must be entered through the telephone'skeypad.

Illustratively, some of the information associated with a system usermay be required to be unique. For example, in an embodiment of theinvention in which transaction participants may be identified by theirelectronic mail addresses, the system may require a one-to-one mappingbetween addresses and users. In another embodiment users may beidentifiable by telephone numbers. Again, the system may allow eachtelephone number to be associated with only a single user, althoughextension numbers could, perhaps, be added to differentiate betweenmultiple users reachable at one number. One reason for this limitationis to allow a value exchange participant to identify another participantusing a common identifier that is, or may be, already known. In onealternative embodiment, however, a user may be known by an accountnumber or other identifier generated by or for the system. In anotheralternative embodiment, some or all users may be identified by multipleidentifiers, in which case multiple users may be associated with aparticular identifier (e.g., electronic mail address) but also haveother identifiers that distinguish them.

After a user is registered with the system, he or she may then establishan initial and/or default method of providing funds. For example, theuser may identify a credit card, a bank account, a debit card or othersource of value to be charged when the user transfers value to anotherperson or at other times when value must be added to the user's systemaccount. The amount of system credit or the limit placed on the user'ssystem activity may be determined in part or in whole by the form ofvalue transfer the user employs, the level of credit or value transferauthorized by the user's financial institution, the degree to which theuser's personal or account information has been verified, etc. Forexample, if the user's street address cannot be verified (e.g., he orshe does not submit the code mailed to the address they provided), orthe address of his/her credit card does not match his/her mailingaddress, or the user's credit card limit is low, then he or she may belimited to a first level of system usage. If, however, the user'spersonal or financial information is verified and/or their credit cardlimit is relatively high, he or she may be allowed to transfer much morevalue through the system. In short, the level of trust, authentication,verification or security that the user provides to the system may affectthe amount or level of system usage the user is granted.

Until a user submits credit or debit information his or her system limitmay be kept at zero, indicating that he or she is not authorized totransfer value to other parties. The user may, however, be able toreceive value transfers as soon as he or she is registered.

A user may also be able to place value in his or her system accountthrough direct deposit, a personal check, electronic funds transfer,etc. Illustratively, however, funds submitted via these methods are notavailable for transfer until they clear. Users may choose multiplemethods of depositing value into their accounts (and retrieving valuefrom their accounts) and may be required to provide whatever informationis necessary (e.g., bank routing or account number) to implement thosemethods.

Registration may or may not be required before a user can download andinstall software configured to allow a user to make a value exchange. Asoftware download may be part of the registration process or may,alternatively, be conducted before or after a user registers. Thefollowing is a description of a software download/installation processaccording to one embodiment of the invention.

To receive the software the user first connects his client device to anappropriate system server (e.g., communication server 104 orsynchronization server 106 of the system of FIG. 1). The user makes achoice to download the software and may need to identify his or herdevice so that the correct software is provided. A registered user mayalso identify himself to the system, in which case the system mayautomatically determine (e.g., by communicating with the user's deviceor referring to account information in database 102) whether the userneeds to update his software.

The software that is downloaded may depend upon the user's normal orexpected method of accessing the system. For example, if the useremploys a portable device the downloaded software may be tailored to theparticular device to allow it to communicate and interact directly withthe system. If the portable device is a disconnectable device that mustbe docked with or otherwise connected to another computer system (e.g.,a desktop or workstation, herein termed a “conduit” computer) in orderto communicate with the system, then the downloaded software may includemodules for the disconnectable device and/or the other computer system.

The appropriate software is then copied to the user's device. Othersoftware, perhaps provided by a manufacturer or vendor of the user'sdevice may need to be in operation in order to fully install the systemsoftware. For a disconnectable portable computing device, a firstsoftware module is installed on the conduit computer, after which thedevice may be docked in order to install a second module on the device.The first module may be configured to synchronize the user's locallystored data and information with synchronization server 106, while thesecond module may be configured to conduct disconnected transactions andcommunicate them to the conduit computer. Thus, after a transaction isconducted with the client while disconnected, it is communicated to theconduit computer, which then synchronizes with synchronization server106. The client software module may be considered a “wallet”application.

Illustratively, after new software is downloaded, and before the usercan use his portable device to transfer value to another person, he mustbe authenticated to the system. Thus, in one embodiment of the systemthe user inputs his username (e.g., account name, electronic mailaddress or other system identifier) and password, which the conduitpasses to the system (e.g., synchronization server 106, security server110) for verification. If the user is verified, a pair of cryptographickeys may be generated (e.g., by the conduit computer or security server110). In the presently described embodiment the user's conduit computergenerates the key pair and passes the public key to the system to besigned. The signed key may be returned in encrypted form (e.g.,encrypted with the user's PIN). Illustratively, both the private key andsigned public key are then stored only on the user's portable device(i.e., not on the conduit).

When a user installs new software (e.g., a new version), unclearedtransactions may be automatically cleared (with synchronization server106) or archived. If the user installs new software on a differentdevice, the digital certificate on the original device may beinvalidated.

The foregoing descriptions of embodiments of the invention have beenpresented for purposes of illustration and description only. They arenot intended to be exhaustive or to limit the invention to the formsdisclosed. Accordingly, the above disclosure is not intended to limitthe invention; the scope of the invention is defined by the appendedclaims.

1. A method comprising: receiving, by a networked system, a request froma wallet application on a mobile device of a first user, the requestindicating a transfer of a value to a second user, the value associatedwith a source selected from a plurality of sources associated with auser account of the first user, the plurality of sources associated withmonetary values and non-monetary values; causing the transfer of thevalue indicated in the request; and causing an update, by a hardwareprocessor, to the source of the value to reflect the transfer of thevalue to the second user.
 2. The method of claim 1, wherein thenon-monetary values comprise a voucher or points.
 3. The method of claim1, wherein the non-monetary values comprise a discount.
 4. The method ofclaim 1, wherein the non-monetary values comprise a coupon.
 5. Themethod of claim 1, wherein the non-monetary values comprise acertificate.
 6. The method of claim 1, wherein the non-monetary valuescomprise at least one of frequent flier miles, a credit, a debit, orbarter points.
 7. The method of claim 1, further comprising:establishing a connection with the mobile device via the walletapplication; receiving a user identifier associated with the useraccount of the first user; and providing access to information includingamounts of the plurality of values associated with the user accountbased on the user identifier.
 8. The method of claim 1, wherein thecausing the transfer comprises exchanging the value in a monetary valueinto a non-monetary value.
 9. The method of claim 1, further comprisingreceiving a selection of the source of the value from which to transferthe value to the second user.
 10. A machine-readable medium having notransitory signals and storing instructions that, when executed by oneor more processors of a machine, cause the machine to perform operationscomprising: receiving a request from a wallet application on a mobiledevice of a first user, the request indicating a transfer of a value toa second user, the value associated with a source selected from aplurality of sources associated with a user account of the first user,the plurality of sources associated with monetary values andnon-monetary values; causing the transfer of the value indicated in therequest; and causing an update to the source of the value to reflect thetransfer of the value to the second user.
 11. The machine-readablemedium of claim 10, wherein the non-monetary values comprise a voucheror points.
 12. The machine-readable medium of claim 10, wherein thenon-monetary values comprise a discount.
 13. The machine-readable mediumof claim 10, wherein the non-monetary values comprise a coupon.
 14. Themachine-readable medium of claim 10, wherein the non-monetary valuescomprise a certificate.
 15. The machine-readable medium of claim 10,wherein the non-monetary values comprise at least one of frequent fliermiles, a credit, a debit, or barter points.
 16. The machine-readablemedium of claim 10, wherein the operations further comprise:establishing a connection with the mobile device via the walletapplication; receiving a user identifier associated with the useraccount of the first user; and providing access to information includingamounts of the plurality of values associated with the user accountbased on the user identifier.
 17. The machine-readable medium of claim10, wherein the causing the transfer comprises exchanging the value in amonetary value into a non-monetary value.
 18. The machine-readablemedium of claim 10, further comprising receiving a selection of thesource of the value from which to transfer the value to the second user.19. A system comprising: one or more servers configured to: receive arequest from a wallet application on a mobile device of a first user,the request indicating a transfer of a value to a second user, the valueassociated with a source selected from a plurality of sources associatedwith a user account of the first user, the plurality of sourcesassociated with monetary values and non-monetary values; cause thetransfer of the value indicated in the request; and cause an update tothe source of the value to reflect the transfer of the value to thesecond user.
 20. The system of claim 19, wherein the one or more serversare further to: establish a connection with the mobile device via thewallet application; receive a user identifier associated with the useraccount of the first user; and provide access to information includingamounts of the plurality of values associated with the user accountbased on the user identifier.